Payment system

ABSTRACT

An electronic transaction payment system is provided having a vendor terminal associated with a vendor who provides goods or services to a purchaser, a vendor smart-card and a vendor smart-card reader for transmitting data to and receiving data from the vendor smart-card. The system also includes a purchaser smart-card reader which is connected to the vendor terminal and which is operable for transmitting data to and receiving data from a purchaser smart-card. In operation, payment for goods purchased by the purchaser is made between the purchaser smart-card and the vendor smart-card. In a preferred embodiment, the payment data is encrypted using an encryption key specific to the transaction between the purchaser and the vendor. A third party registry terminal may also be provided for providing validation of the vendor and/or the purchaser.

This invention relates to a payment system and in particular but notexclusively to a smart-card payment system wherein an entire purchaseoperation is explicitly linked as a single transaction and a variablelevel of user validation is provided.

Existing payment systems suffer from a number of drawbacks. The use ofcash for example is limited by the requirement for the actual transferof possession of physical tokens and by the fact that if lost or stolen,cash is usable without restriction by a finder or thief.

The use of cheques goes some way to overcome the security worries ofcarrying cash but still requires the transfer of a physical token.Cheques also introduce the problem of “clearing time”, that is, timetaken by banks to actually transfer money from the cheque writer'saccount to the cheque receiver's account. In addition, there is apossibility with a cheque that a bank may refuse to honour a chequewritten by an account holder because the account holder has insufficientfunds in their account. In this circumstance, the receiver of the chequehas then transferred ownership of goods or provided a service and hasreceived no payment for those goods or that service.

For ordering goods by telephone or using the internet, cash is totallyunsuitable and cheques are very inconvenient because to pay by chequefor goods ordered by telephone or over the internet requires the orderplaced using the telephone or the internet to be confirmed in writingaccompanied by a cheque for payment.

More suitable for use with internet or telephone orders are credit anddebit cards. When using a credit card, payment for the goods is actuallymade to the retailer by a credit card company which allows the creditcard user to spend up to a predetermined borrowing limit for purchases.Purchases made with a credit card must be paid for to the credit cardcompany within a predetermined time limit or interest on the moneyborrowed becomes payable. Debit cards on the other hand provide for anelectronic transfer of funds direct from the card holder's bank accountto the retailer's bank account. Credit and debit cards also suffer fromthe problems of “clearing time”.

Both credit and debit cards use conventional magnetic stripe cardtechnology. Both payment systems also suffer from processing chargesinherent in the system. These processing charges are typically levied onthe vendor and may be in the range of one to four percent of the saletransaction. Sometimes all or part of this cost is passed onto thepurchaser. This transaction cost has a minimum size which is set by thebanks and credit card companies operating the cards. As a result, it iseconomically disadvantageous to process small value transactions usingcredit and debit cards.

Credit and debit cards do however have the advantage for telephone andinternet transactions that there is no requirement for the transfer ofphysical tokens. They can therefore be used to make purchases or toreserve restaurant tables for example, without the need for postal orpersonal transfer of payment. The use of a credit card to make apurchase provides the purchaser with extra protection in that the creditcard company must cover the cost of goods paid for on the card, over acertain minimum value, which are not delivered or with which there arecertain other problems. In addition, the credit card operator pays thevendor regardless of whether or not the purchaser ever repays that moneyto the credit card company. Thus both vendor and purchaser benefit fromthe use of a credit card. However, for telephone and internettransactions, which are defined by the credit card operator as “cardholder not present” transactions, the risk of loss rests with theretailer not the card operator. Thus, it becomes less beneficial for avendor to accept credit cards as payment for telephone and internetorders because they must pay the handling fee and they receive noprotection.

The so-called electronic purse (e.g. the Mondex Electronic Purse System)has been developed to eliminate the problems of carrying actual cash andof the minimum processing charges for small debit or credit cardtransactions. The electronic purse makes use of smart-card or chip-cardtechnology. To use the electronic purse, the user must either load cashonto the smart-card electronic purse at a vending machine or at the deskof a load agent such as a Post Office, or the user must transfer fundsfrom their bank account or credit card to the smart-card electronicpurse. The purse may then be used to make purchases in the real world,over the internet or over the telephone, subject to the telephone beingwith an appropriate smart-card reader.

From a transaction processing point of view, full clearing would only berequired when loading the purse, which would normally be a medium tolarge value transaction and therefore acceptable. Payments could bebatched into daily totals and cleared to the retailers as single dailytransactions, again being of reasonable size. There would be norequirement to account for every transaction back to the card holder,all that would happen would be that payment would be made out of thecash float created when taking cash to load the electronic purse.

Thus from a bank's point of view, the electronic purse solved a majorproblem. However, from the card holder's point of view the electronicpurse is less successful and all open electronic purse trials havetended towards failure in terms of take up. Among the reasons for thepoor take up are: poor education of the card holders, small scale trialsleading to purse being usable at only a few locations, lock-in of cardholder money to the card and places it could be used, no interest onprepayment, requirement for a bank account to back the electronic purseand fear over security and transaction accountability.

The requirement for a bank account to back the electronic purse is amajor failing of the system. This is because many people who could bestbenefit from an electronic purse (or other prepaid mechanisms) are thosepeople who do not have bank accounts and who are therefore automaticallyexcluded from using cheques, debit cards or credit cards. Approximatelytwenty percent of the UK population are disallowed by the banks fromhaving a bank account. It should be noted that the Mondex ElectronicPurse System was specifically developed to allow use by persons nothaving a bank account, however the operators still insisted on a userhaving a bank account before a card would be issued.

Regarding fear over security and transaction accountability, the problemis one of how much the card holder trusts the retailer. For example, howdoes the card holder know how much credit is stored on his or her cardand how do they know how much is removed? For internet transactions,this problem grows to incorporate issues such as: how to identify howmuch is being deducted from the card, how to identify the other party tothe transaction, how to identify the location of the other party to thetransaction, whether goods will actually be shipped, whether the paymentmade will actually go to the vendor, whether the vendor will recognisethe payment as being against the goods purchased, whether the paymentcould be fraudulently redirected and concerns over who will be able tosee the delivery address specified.

The existing electronic purse schemes use so-called smart-cards orchip-cards. These are cards having a microprocessor and memory mountedonto or into a card, with an interface provided for the microprocessorto be powered and interfaced with by a reader. The standards forsmart-cards where the interface is by means of physical connectionterminals are set out in ISO 7816. The standards for smart-cards wherethe interface is by means of radio signals (including supply of power)are set out in ISO 14443.

In an attempt to address some of the above problems, a number of banksand financial card operators including Mastercard and Visa have agreed asmart-card standard for credit and debit services such that a retailercould have a common terminal to support all smart credit and debit cardsin a similar manner to the current situation with magnetic stripe cards.This standard is known as EMV (Europay Mastercard Visa) and it appliesto credit and debit services on smart-cards as well as the terminals tosupport them. An electronic purse system based on the EMV specificationsis the common electronic purse specifications (CEPS) with which theEuropean Standard Organisation (CEN) has been involved. CEPS requires apersonalised system and additional hardware to identify the cardholderin order for him or her to digitally sign and certify all CEPStransactions. Further, for use in telephone or internet transactions,there is a requirement in CEPS for digital signatures. There iscurrently no worldwide or European standard for producing digitalsignatures. Such digital signatures require a public key infrastructureadministered by a certification authority which acts as a library ordirectory of public keys. In addition, when it supplies a public key itadds a certificate signed with its own private key such that therecipient can then validate that the public key information is genuinewithin Europe, the various public key infrastructures that currentlyexist are not compatible and therefore such digital signatures are notinteroperable across services and countries. Thus the fullimplementation of CEPS will be delayed until such standardisation can becompleted.

In summary therefore, cash and cheques require the exchange of physicaltokens and are therefore totally unsuitable for real time trading bytelephone or over the internet. Credit and debit cards and chequessuffer from clearing time delays. Credit and debit cards are alsounsuitable for small value transactions due to the processing chargesincluded. Electronic purses have been unpopular due to the “tied-in”nature of the funds and the small number of places where trials haveallowed use of the purses. Credit and debit cards and electronic purseshave the additional problem for internet and telephone transactions ofrequiring trust between purchaser and vendor. CEPs has the drawback ofan awkward and non-standard security system.

Aspects of the present invention relate to a smart-card payment systemwherein:

-   -   provision is made for payment by means of prepaid value stored        on a card held by the purchaser (the so-called electronic        purse);    -   provision is made for payment by means of credit by a third        party on behalf of the purchaser and accessed by means of a        smart-card held by the purchaser (the so-called credit card        facility);    -   provision is made for payment by means of prepaid value stored        on behalf of the purchaser and accessed by means of a smart-card        held by the purchaser (the so-called debit card facility);    -   provision is made for different levels of validation between the        purchaser and the vendor including third party validation if        required;    -   the provision of a third party registry to permit the movement        of value or funds between the registry and the smart-card;    -   payment may be anonymous or personalised;    -   the purchaser may use either of the electronic purse and debit        card facilities without having to pass any means test, credit        check or hold a bank account; and    -   a system in which an entire purchase operation is inextricably        linked as a single transaction and variable levels of user        (purchaser and/or vendor) validation is provided.

The present invention seeks to address difficulties of the prior art.According to one aspect, there is provided an electronic transactionpayment system comprising a vendor terminal associated with a vendor whoprovides goods or services to a purchaser; a vendor smart-card; a vendorsmart-card reader for transmitting data to and receiving data from thevendor smart-card; a purchaser smart-card reader for transmitting datato and receiving data from a purchaser smart-card. The vendor terminalcomprises means for processing requests for vendor goods or servicesfrom the purchaser, means for generating cost data identifying the costof requested goods or services and means for transmitting the cost datato the purchaser smart-card. The purchaser smart-card includes means forreceiving the cost data from the vendor terminal and means forencrypting the payment data for transmission back to the vendorsmart-card. The vendor smart-card also includes means for receiving theencrypted payment data and means for decrypting the payment data toobtain payment for the requested goods or services.

Preferably, all communications relating to the purchase of the goodspass from the purchaser's smart-card to the vendor and are encryptedwith an encryption key specific to the current transaction. In this way,payment of the goods and/or services can be inextricably linked to thetransaction itself. The invention can be applied for electronic tradingon, for example, the Internet and can be used at traditional points ofsale.

In a preferred embodiment, a third party registry is provided to provideguarantees for the purchaser and/or the vendor if required. The thirdparty registry may provide additional support as requested and to alevel requested by the vendor or purchaser, to ensure trust andconfidence in the trade. Either party in the transaction may choose tovalidate the credentials of the other party by making a reference to thethird party registry. In this case, the registry will provide theinformation and may levy an appropriate fee.

Preferred embodiments of the present invention will now be described byway of example only with reference to the accompanying drawings, inwhich:

FIG. 1 shows an internet enabled computing environment in which thepresent invention may operate;

FIG. 2 is a block diagram showing the main functional elements of avendor terminal and a purchaser terminal shown in FIG. 1;

FIG. 3 is a block diagram showing the main functional elements of aregistry terminal shown in FIG. 1;

FIG. 4 is a block diagram showing the main functional elements of asmart-card shown in FIG. 1;

FIG. 5 is a flow chart showing the main processing steps performed bythe terminals in FIG. 1 to process a transaction;

FIG. 6 is a flow diagram showing in more detail the processing stepsinvolved in a product selection and price agreement step which formspart of the processing steps shown in FIG. 5;

FIG. 7 which comprises FIGS. 7A and 7B is a flow diagram showing in moredetail the processing steps involved in a secure link set-up step whichforms part of the processing steps shown in FIG. 5;

FIG. 8 is a flow diagram showing in more detail the processing stepsinvolved in a purchaser validation step which forms part of theprocessing steps shown in FIG. 5;

FIG. 9 is a flow diagram showing in more detail the processing stepsinvolved in a vendor validation step which forms part of the processingsteps shown in FIG. 5;

FIG. 10 is a flow diagram showing in more detail the processing stepsinvolved in a delivery confirmation step which forms part of theprocessing steps shown in FIG. 5;

FIG. 11 which comprises FIGS. 11A and 11B is a flow diagram showing inmore detail the processing steps involved in a payment and receiptingstep which forms part of the processing steps shown in FIG. 5;

FIG. 12 which comprises FIGS. 12A and 12B is a flow diagram showing inmore detail the processing steps involved in a purchaser validation stepwhich forms part of the processing steps shown in FIG. 5 according to analternative embodiment;

FIG. 13 is a flow diagram showing in more detail the processing stepsinvolved in a purchaser validation step which forms part of theprocessing steps shown in FIG. 5 according to a further alternativeembodiment;

FIG. 14 which comprises FIGS. 14A and 14B is a flow diagram showing inmore detail the processing steps involved in a vendor validation stepwhich forms part of the processing steps shown in FIG. 5 according toanother alternative embodiment;

FIG. 15 is a flow diagram showing in more detail the processing stepsinvolved in a payment and receipting step which forms part of theprocessing steps shown in FIG. 5 according to another alternativeembodiment;

FIG. 16 is a flow diagram showing in more detail the processing stepsinvolved in a payment and receipting step which forms part of theprocessing steps shown in FIG. 5 according to another alternativeembodiment;

FIG. 17 is a flow diagram showing in more detail the processing stepsinvolved in a payment and receipting step which forms part of theprocessing steps shown in FIG. 5 according to a further alternativeembodiment;

FIG. 18 which comprises FIGS. 18A and 18B is a flow diagram showing themain processing steps required to convert currency on an account card;

FIG. 19 shows an internet enabled face-to-face retail environment inwhich the present invention may operate;

FIG. 20 is a block diagram showing the main functional elements of aretailer terminal shown in FIG. 19.

OVERVIEW

In the following description it is assumed that the purchaser's terminalis already connected to the internet, as is the vendor's terminal. Also,using his or her terminal, the purchaser has browsed the vendor'swebsite and has selected a product or products that he or she wishes topurchase.

Referring to FIG. 1, the internet enabled computing environment 1 inwhich the payment system of the present embodiment is operated,comprises a purchaser terminal 5, a vendor terminal 21 and a registryterminal 25 which communicate electronically with one another via anetwork such as the internet 19. Attached to the purchaser terminal 5 isa smart-card slot 7 _(p) into which a purchaser smart-card 3 may beinserted. In this embodiment, the purchaser smart-card 3 must beinserted into the smart-card slot 7 _(p) in order for any transaction tobe made with a vendor. Also attached to purchaser terminal 5 is amonitor 9 for displaying data to a user, a keyboard 11 and a mouse 13which provide a user interface to the purchaser terminal 5 and a modem15 for communicating via the internet 19. An electrical, electromagneticor optical signal 17 is transmitted from and received by modem 15 inorder to facilitate communication via the internet 19.

As shown in FIG. 1, the vendor terminal 21 also includes a monitor 9, akeyboard 11, a mouse 13, a modem 15 and a smart-card slot 7 _(v) forreceiving a vendor smart-card 23.

Attached to the registry terminal 25 is a registry smart-card server 27having a plurality of registry account smart-cards permanently insertedin card slots 7 _(r) therein. In this embodiment, there is typically oneregistry account logical smart-card for each user of the payment system,although in practice many such logical smart-cards will be grouped ontoone master smart-card which will substantially reduce the smart-card andsmart-card reader requirement at the registry. Each registry account isrepresented by a logical record on a master account card. The number ofmaster account cards will be equal to the number of accounts divided bythe number of logical account records on each card. Since theinformation on the card need only contain an account number and balance,with further information held in a connected hard disk at the registry25, there could be as many as five thousand logical account records permaster card.

In this embodiment, every registry account is represented by a diskbased record at the registry 25. As and when a registry account is to beaccessed for whatever reason, key information is copied to a sparelogical account slot in a master card, so that card to card working maytake place. The number of master cards required will be just greaterthan the number of parallel transactions required to provide adequateperformance. After a transaction is completed, the disk record isupdated. The card record is retained until the logical account slot isrequired. This provides a form of caching to provide better performancefor those actively using their smart-cards and registry. Typically, aretailer's account will be more active than a purchaser's account.

FIG. 2 shows the functional elements of the purchaser terminal 5 and thevendor terminal 21. As shown, these terminals include a centralprocessing unit (CPU) 41 which carries out processing operations inaccordance with instructions stored in a working memory 43 and inaccordance with user input received either via the keyboard and mouseinterface 49 or the smart-card reader 53. The terminals also include amonitor interface 51 for interfacing to the display, a modem interfacefor interfacing with the modem 15 and a non-volatile software store 47(such as a hard disk) which stores the processing instructions used tocontrol the operation of the CPU 41 together with other data used by theterminals. As shown, these components are connected together via a bus45.

FIG. 3 shows the functional elements of the registry terminal 25. Asshown, the registry terminal 25 also includes a CPU 41, a working memory43, a software store 47, a monitor interface 51 and a modem interface 55which are all connected together by a bus 45. In addition, thesmart-card server 27 is connected to the registry terminal 25 via asmart-card server interface 57.

FIG. 4 shows the functional elements of a smart-card 3,23 used in thisembodiment. As shown, the smart-card 3,23 includes a card controller 62which carries out processing operations stored in a processinginstructions store 64 in accordance with instructions received from thepurchaser terminal 5, vendor terminal 21 or the registry terminal 25 viaa card reader interface 66. Coupled to the card controller 62 is a moneystore 68, which holds data representing the amounts of money held on thesmart-card 3,23. The smart-card 3,23 also includes a user validationstore 70 which stores information about the smart-card owner such as theowner's name, age, address etc. When a smart-card 3,23 is used to make atransaction, a single unique session ID is generated by a session IDgenerator 72 on the smart-card 3,23. The generated session ID isencrypted by an encryption engine 74 also on the smart-card 3,23 andthen stored in a session ID store 76. As will be described in furtherdetail later, this session ID is appended to all subsequent messagesrelated to the current transaction by the card controller 62, and thecard controller 62 is also operable to compare the session ID ofreceived messages to the stored session ID to check that the messagebelongs to the current transaction.

As shown in FIG. 4, the smart-card 3,23 further comprises a key store 78for storing data needed for encryption and decryption, such as publicand private keys, which will be described in more detail later. The keystore 78 is coupled to the encryption engine 74, so that messagesrelating to a transaction can be encrypted by the encryption engine 74using the stored encryption key data, before transmission back to theterminal via the card reader interface. Also coupled to the cardcontroller 62 is a transaction log store 80 for storing datarepresenting each transaction made using the smart-card 3,23 and aregistry data store 82 for storing details of the user account held atthe registry.

Referring now to FIG. 5, there are shown the principal functional stepswhich must be performed to complete a purchase transaction using thepayment system of the present embodiment. As shown, at step S4-1, theuser, having selected a desired product already, provides inputindicating a product selection to the purchaser terminal 5. Thepurchaser terminal 5 then communicates with the vendor terminal 21 bytransmitting signals 17 between the modems 55 attached to each of thepurchaser terminal 5 and the vendor terminal 21 via the internet 19. Thepurchaser terminal 5 transmits the product selection to the vendorterminal 21, which then returns price and delivery terms to thepurchaser 5. The terms are then displayed by the purchaser terminal 5 onmonitor 9 and the purchaser terminal 5 then awaits an input from thepurchaser to indicate approval or disapproval of those terms via thekeyboard 11 or mouse 13. The inputted approval or disapproval is thencommunicated by the purchaser terminal 5 to the vendor terminal 21 viathe internet.

Next, at step S4-3, the purchaser smart-card 3 inserted in the purchaserterminal 5 and vendor smart-card 23 inserted in the vendor terminal 21create and exchange secure encryption keys (which are stored in therespective key stores 78 of the purchaser and vendor smart-cards 3,23)to be used throughout the payment session and to be used as the basisfor the secure exchange of information using data encryption betweenterminals. Before payment is made, however, in this embodiment thesmart-cards 3,23 return control to the terminals so that user validationcan be performed. This is initiated at step S4-5, where the vendorterminal 21 displays on monitor 9 a request for user input to indicatewhether validation of the purchaser should be undertaken. Such input isreceived via the keyboard 11 or mouse 13. If validation is to beundertaken, processing proceeds to step S4-7 where validation isperformed. To perform validation, as will be described in more detailbelow, the vendor terminal 21 communicates with purchaser terminal 5 orthe registry 25 via the internet 19 to request identifier data about thepurchaser so that certain pre-specified levels of knowledge about thepurchaser are obtained.

Following purchaser validation, or if purchaser validation is not to beundertaken, the processing proceeds to step S4-9, where the purchaser'sterminal 5 displays on monitor 9 a request for user input to indicatewhether validation of the vendor should be undertaken. If vendorvalidation is required, then at step S4-11, validation of the vendor isperformed, which is a similar process to that described above forpurchaser validation. Following such validation, or if validation of thevendor is not required, processing continues at step S4-13. At thisstep, it is decided whether or not delivery of the product will berequired. To determine whether delivery is required, the vendor terminal21 analyses the delivery terms agreed at step S4-1. From these terms itwill be clear whether anything is to be delivered. It is to beunderstood that delivery may include electronic transfer of data as wellas postal delivery of physical items. If delivery is required, then thedelivery data is confirmed at step S4-15 where the purchaser terminaltransmits the relevant delivery address (which may be a postal address,an e-mail address or an FTP (file transfer protocol) server address forexample) to the vendor terminal 21. Following this, or in the event thatdelivery is not required, control is passed back to the smart-cards 3,23where payment and receipting is performed at step S4-17. In this step,the purchaser terminal 5 causes the appropriate value to transfer fromthe money store 68 of the purchaser smart-card 3 to the money store 68of the vendor smart-card 23, during which a receipt message istransferred from the vendor smart-card 23 to the purchaser smart-card 3.

An overview of the smart-card payment system of this embodiment has beengiven above. The system offers a number of advantages, including:

-   -   i) the provision of a single session ID which links all messages        in a transaction including the terms, user validation and        payment, thereby inextricably linking the payment to the        transaction;    -   ii) the provision of different levels of user (purchaser and/or        vendor) validation; and    -   iii) the provision of a third party registry for validation of        one or more of the parties to a transaction if required.

These and other advantages of the payment system of the presentembodiment will become apparent from the following more detaileddescription.

Product Selection

FIG. 6 shows an expansion of step S4-1 in which the purchaser terminal 5transfers data describing a product selection to the vendor terminal 23and the purchaser and vendor terminals 5, 23 communicate to establishthe price and delivery terms for the transaction. In FIG. 6, the stepsundertaken by the purchaser's terminal are shown to the left hand sideof the central dotted line and those steps undertaken by the vendor'sterminal are shown on the right hand side of the central dotted line.

At step S5-1, the purchaser terminal 5 receives product selection inputfrom the user via the keyboard 11 or mouse 13, and at step S5-3 productselection data is transmitted to the vendor terminal 21 by transmittingsignals 17 from the modem 55 connected to the purchaser terminal 5 tothe modem 55 connected to the vendor terminal 21 via the internet 19.The product selection data is received by the vendor terminal 21 at stepS5-5. At step S5-7, the vendor terminal 21 compares the productselection data to a product database to determine the price of theproduct and at step S5-11 the price and any necessary delivery termsdata are transmitted to the purchaser terminal 5. At step S5-13 thepurchaser terminal 5 receives the price and delivery terms data, whichdata is then displayed to a user at step S5-15. The purchaser terminal 5then receives acceptance input from the user at step S5-17 and at stepS5-19 the terminal 5 processes the input from the user to determinewhether the user accepted the price and delivery terms. If the price anddelivery terms are not accepted, then at step S5-21 the purchaserterminal 5 transmits that the terms are not accepted to the vendorterminal 21 which is received at step S5-23. The transaction processthen ends. If the user does accept the price and delivery terms, then atstep S5-25 the purchaser terminal 5 transmits that the terms have beenaccepted and at step S5-27 the vendor terminal 21 receives that theterms have been accepted. Following this, the selection of product andagreement of price and delivery terms is complete and referring again toFIG. 5 processing then continues to step S4-3.

Establish Secure Link

The processing of step S4-3 is shown in more detail in FIG. 7. At stepS6-1, the vendor terminal 21 transmits a request for the purchaser toidentify how payment is to be made. At step S6-3, that request isreceived at the purchaser terminal 5 and at step S6-5 the purchaserterminal 5 transmits that the payment system of the present embodimentis to be used, ie payment using the smart-cards 3,23. This is receivedat step S6-7 by the vendor terminal 21.

Once it has been established that the payment system of the currentembodiment is to be used, control passes to the smart-cards 3,23 whichestablish a secure session between themselves. This is achieved, in thisembodiment, using so called public key encryption where each partytransmits to the other a public key with which data should be encrypted.It is only possible to decrypt the encrypted data using a private keywhich is retained by each party. The present embodiment uses a modifiedpublic key encryption scheme which allows a new, unique session ID to beused for each transaction in connection with the asymmetric key pair.

The setting up of the secure session begins at step S6-9 where thevendor smart-card 23 transmits its public key from its key store 78 tothe purchaser smart-card 3. The purchaser smart-card 3 receives thepublic key from the vendor smart-card 23 at step S6-11 and stores it inits key store 78. Next, at step S6-13, the purchaser smart-card 3generates, using the session ID generator 72, a purchaser session IDwhich it appends to all communications transmitted to the vendorsmart-card 25 during the current session. In the present embodiment, thepurchaser session ID takes the form of a block of data made up of a timestamp, a random number, a terminal ID and a card ID, all encrypted usingthe purchaser smart-card's public key (so that only the purchasersmart-card 3 can decrypt the purchaser session ID). Then at step S6-15,the purchaser smart-card 3 encrypts the purchaser session ID using thevendor smart-card's public key and transmits this to the vendorsmart-card 23, along with its own public key. At step S6-17, the vendorsmart-card 23 receives and decrypts the data to recover the purchasersession ID and the purchaser public key, which it stores within thesession ID store 76 and the key store 78 respectively of the vendorsmart-card 23. Next, at step S6-19, the vendor smart-card 23 generates avendor session ID using its session ID generator 72. In the presentembodiment, the vendor session ID comprises a time stamp, a randomnumber, a terminal ID and a card ID, all encrypted using the vendorsmart-card's public key (so that only the vendor smart-card 23 candecrypt the vendor session ID). At step S6-21, the vendor smart-card 23then encrypts the vendor session ID using the purchaser smart-card'spublic key and transmits it to the purchaser smart-card 3. At steps6-23, the purchaser smart-card 3 receives and decrypts the data torecover the vendor session ID which it stores in its session ID store76. At step S6-25, the purchaser smart-card 3 transmits a message to thevendor smart-card 23 stating that the vendor session ID has beenreceived, which message is received by the vendor smart-card 23 at stepS6-27.

The session ID generated by each of the purchaser smart-card 3 and thevendor smart-card 23 will be different for a given session (because ofthe time stamp and the random number), but they will be inextricablylinked to the one session and the two smart-cards. In the presentembodiment, the session IDs are added to every transfer of data passingbetween the terminals after it has been established that the paymentsystem of the present embodiment is to be used. This will take the formof appending both session IDs to the end of the message and thenencrypting the whole with the recipient's public key. By performing theencryption each message is protected from being read by an unauthorisedparty, and by using the session ID each message is digitally signed tocertify that the sender of the data is who they claim to be and that themessage is valid. It should be noted that only the purchaser smart-card3 and the vendor smart-card 23 will be able to: validate the sessionIDs, encrypt data and decrypt data. The cards will be use their ownencryption engines 74 for this purpose, rendering it unnecessary for theterminals to be secure devices.

Part of the session will include the transmission of a user input suchas acceptance or refusal of validation information supplied and/ordelivery data. This will be entered as plain text (i.e. unencrypted anduncoded) by the vendor or purchaser and then passed to the localsmart-card for appending of session IDs, encryption and transfer to theother party. Again, it is not necessary for the terminal to be a securedevice.

Purchaser Validation

Referring now to FIG. 8, the processing steps to perform the validationof a purchaser (step S4-7) will now be described.

First, the vendor or vendor terminal 23 must determine the level ofvalidation required at step S7-1. Note that if it is determined at stepS4-5 that no validation is required, then the processing steps shown inFIG. 8 will not be undertaken. In this embodiment, the level ofvalidation may be selected manually by the vendor, in which casevalidation options will be displayed by the vendor terminal 21 onmonitor 9 and which will then await an input from the vendor via thekeyboard 11 or the mouse 13. Alternatively, the level of validation maybe selected by the vendor terminal automatically, in which case thecharacteristics (eg value, nature etc) of the transaction will becompared to a predetermined set of rules for deciding the level ofvalidation required.

Once the level of validation has been determined, the vendor terminal 21will transmit a request for the purchaser validation at step S7-3indicating the level of validation required. In the present embodiment,it is assumed that a relatively low level of validation is required.Therefore the validation request is sent to the purchaser terminal 5,not the registry 25. At step S7-5, the purchaser terminal 5 receives thevalidation request and at step S7-7 transmits the requested validationdata (which may either be input by the purchaser or is stored in thevalidation store 70 of the purchaser smart-card 3). At step S7-9 thevendor terminal 21 receives the validation data and at step S7-11determines whether the validation data received is acceptable. This isdone either automatically by comparing the received validation data withpre-stored data or manually by displaying the validation data to thevendor and awaiting confirmation from the vendor that it is acceptable.If the validation data is unacceptable then processing continues at stepS7-13 where the vendor terminal 21 transmits to the purchaser terminal 5that the validation data provided was unacceptable. This is received atstep S7-15 by the purchaser terminal 5 and then the transaction processends. Alternatively, if the validation data is acceptable, processingcontinues at step S7-17 where the vendor terminal 21 transmits to thepurchaser terminal 5 that the validation data provided was acceptableand at step S7-19 the purchaser terminal 5 receives this. The validationof the purchaser is then complete and, referring again to FIG. 5,processing continues at step S4-9.

Vendor Validation

If it is decided at step S4-9 that validation of the vendor is required,as described above, then the steps shown in FIG. 9 are performed (stepS4-11). The processing of FIG. 9 is substantially the same as theprocessing of FIG. 8, except that it is the purchaser terminal 5requesting the validation data and the vendor terminal 21 transmittingit.

Thus at step S8-1, the purchaser terminal 5 determines the level ofvalidation that is required in substantially the same manner asdescribed above with reference to purchaser validation in FIG. 8,following which it transmits a vendor validation request either to thevendor terminal 21 or to the registry 25 at step S8-3. In the presentembodiment it is assumed that a relatively low level of validation isrequired. Therefore the validation request is sent to the vendorterminal 21, not the registry 25. On receiving the vendor validationrequest at step S8-5, the vendor terminal 21 transmits, at step S8-7,the requested validation data (which may either be input by the vendoror is stored in the validation store 70 of the vendor smart-card 23).

Following receipt of the validation data by the purchaser terminal 5 atstep S8-9, the purchaser terminal 5 determines at step S8-11 whether thevalidation data is acceptable. This is done either automatically bycomparing the received validation data with pre-stored data or manuallyby displaying the validation data to the purchaser and awaitingconfirmation from the purchaser that it is acceptable. If the validationdata is decided to be unacceptable, then at step S8-13 the purchaserterminal 5 transmits to the vendor terminal 21 that the validation datais not acceptable and the vendor terminal 21 receives this at step SB-15following which the transaction process terminates. If, however, thevalidation data is determined to be acceptable at step S8-11, then atstep S8-17 the purchaser terminal 5 transmits to the vendor terminal 21that the validation data is acceptable. This acceptance is received bythe vendor terminal 21 at step S8-19 following which the validation ofthe vendor is complete and, referring again to FIG. 5, processingcontinues at step S4-13.

Confirm Delivery Data

If it is determined at step S4-13 that delivery is required, then thedelivery data must be confirmed at step S4-15. This process is shown inmore detail in FIG. 10.

At step S9-1, the vendor terminal 21 requests the delivery data, that isthe delivery address (which may be a postal address or an e-mailaddress, for example) and the name of the person or company to whom theitems should be directed. At step S9-3, the purchaser terminal 5receives the delivery data request and displays on monitor 9, at stepS9-5, a request for a user to enter delivery data. At step S9-7, thepurchaser terminal receives the delivery data input from the user viathe keyboard 11 or the mouse 13 and at step S9-9 transmits the deliverydata to the vendor terminal 21. The vendor terminal 21 then receives thedelivery data at step S9-11, following which the process of confirmingdelivery data is complete and, referring again to FIG. 4, the processingwill continue at step S4-17.

Payment and Receipting

Performing payment and receipting (step S4-17) will now be described ingreater detail with reference to FIG. 11. As mentioned above, control ofthe payment and receipting is carried out in this embodiment by thesmart-cards 3,23.

Starting at S10-1, the vendor smart-card 23 transmits a request forpayment to the purchaser smart-card 3. At step S10-3, the purchasersmart-card 3 receives the request and at step S10-5 transmits thepayment data to the vendor smart-card 23. At step S10-7, the vendorsmart-card 23 receives the payment data and at step S10-9 transmits areceipt for the payment. At this time, the vendor smart-card 23 hasreceived the payment data but has not accepted the payment describedtherein. The purchaser smart-card 3 then receives the receipt at stepS10-11. At step S10-12, the purchaser smart-card 3 validates the receiptby checking that the purchaser session ID has been appended to thereceipt data and that it matches its purchaser session ID stored in thesession ID store 76. If the purchaser session ID is not present andcorrect, then at step S10-13, the purchaser smart-card 23 transmits anerror message to the vendor smart-card 23 stating that the session ID isincorrect. This error message is received by the vendor smart-card 23 atstep S10-14 following which the transaction process ends. On the otherhand, if it is determined at step S10-12 that the purchaser session IDis present and correct, then at step S10-15 the purchaser smart-card 3transmits an acknowledgement that the receipt has been received. Thisacknowledgement is received by the vendor smart-card 23 at step S10-16,following which the vendor smart-card 23 validates the acknowledgementby checking that the vendor session ID has been appended to theacknowledgement data and that it matches the vendor session ID stored inthe session ID store 76. If the vendor session ID is not present andcorrect, then at step S10-18 the vendor smart-card 23 generates an errormessage stating that the vendor session ID is not present and transmitsit to the purchaser smart-card 3 which receives the message at stepS10-19 following which the transaction process ends. If on the otherhand, however, it is determined at step S10-17 that the vendor sessionID is present and correct, then processing continues at step S10-20where the vendor smart-card 23 finalises the order data and accepts thepayment data, thereby actually receiving the payment, to complete thetransaction. The receipt and acknowledgement are validated by eachsmart-card 3 and 23 to ensure the session remains intact. Thetransaction can only be completed if both smart-cards 3 and 23 completethis test successfully. Thus the payment process is inextricably linkedto the purchase transaction, the validation of the parties andacceptance of all terms into a single transaction session including userinput of validation acceptance and possible delivery details. Once thesession has been validated as complete the vendor smart-card 23transmits, at steps s10-21, a message to the purchaser terminal 5 toindicate that the transaction is complete. At step S10-22 the purchasersmart-card 3 receives the transaction complete message following whichthe transaction process terminates. Following completion of thetransaction, the purchaser terminal 5 and smart-card 3 may then be usedto perform other actions unconnected with the purchase.

Validation Level Determination

As described above, it is necessary to determine at step S7-1 and S8-1the level of validation of the other party to a transaction that isrequired. For example, one party may wish to validate the address andother credentials (such as age, legal status or credit worthiness) ofthe other party and also to be guaranteed that purchased goods will bedelivered intact and possibly to a given quality. As discussed above,some of this information, such as name, age or address, is held in thevalidation store 70 on the smart-card of the user and this informationplus further information may be held by the registry 25. Either partymay opt for more or less information from the registry 25, and/or agreater or lower level of guarantee. The registry 25 may implement acharging structure to enable users of the payment system to be chargedfor information held by and requested from the registry 25, or to chargeusers for storing and providing their data to others. Different levelsof payment will be required depending on the amount of validation dataheld by the registry.

In all trades made using the payment system of the present invention,the complete trade, that is selection of goods, agreement to purchase,payment and subsequent expected delivery are based on the honesty of thetwo parties and their acceptance of each other's bona fides and mutualacceptance of the terms of trading. The payment system does not applyany specific trading rules of its own and it is up to both parties toagree terms that overcome any doubts a party may have regarding theother party and the trade. The payment system provides electronicpackaging of a negotiation between the parties such that value does notmove from one party to the other until both parties are satisfied withthe terms.

Thus, each party is able to decide upon the level of trust it has in theother party and if insufficient, to make use of the registry 25 asnecessary until satisfied. For example, two parties trading for thefirst time may both seek the top level of guarantee from the registry25. However, as the parties get to know one another, the trust levelbetween them will increase and their reliance on the registry 25 willdecrease.

Further Embodiments

The first embodiment discussed above made no use of the registry 25 forvalidation or for payment, as it was assumed that only a low level ofvalidation was required and payment was made directly from the purchasersmart-card 3 to the vender smart-card 23. However, either or bothparties to a transaction may wish to validate the other party with theregistry 25 or make payment to or from a registry account card 33. Wherethe registry 25 is to be involved in a transaction, session IDs aregenerated as described above with reference to FIG. 7, to include theregistry (for validation data) and each registry account card used (forpayment) in a secure session. Where the registry 25 is to interact withthe purchaser and vendor, a separate secure session with its own sessionID pair is generated between the registry 25 and the vendor smart-card23 and between the registry 25 and the purchaser smart-card 3. However,if only one of the vendor and purchaser needs to contact the registry 25then a session having a new session ID pair will be generated betweenthe registry 25 and the vendor smart-card 23 or the purchaser smart-card3. Thus the overall transaction will be made up of a number of sessions,each session having its own session ID pair. In this embodiment, toensure a common reference between the various sessions making up thetransaction, each party uses the same session ID in each session of agiven transaction. For example, if the purchaser smart-card 3 hasalready established a session with the vendor smart-card 23 (and hasthus created a purchaser session ID), and then requires a session withthe registry 25, the purchaser session ID used in the session with theregistry 25 will be the same as the purchaser session ID already used inthe session with the vendor smart-card 23. Obviously, the vendor sessionID and the registry session ID will be different to one another.

Referring now to FIG. 12, there will be described a method of performingvalidation of the purchaser using validation data held by the registry25 in which the purchaser is informed of the decision to validate at theregistry 25 and has the option to refuse such validation. Suchprocessing would take the place of the processing described withreference to FIG. 8 above in the first embodiment. It is assumed in themethod shown in FIG. 12 that the registry 25 and the vendor smart-card23 have already established a secure session by means of a processsimilar to that set out above with reference to FIG. 7.

At step S11-1, the level of validation required is determined as in stepS7-1. Next, at step S11-3, the vendor terminal 21 transmits a requestfor validation at the registry 25 to the purchaser terminal 5. At stepS11-5, the purchaser terminal 5 receives the request and at step S11-7decides whether or not to agree to the level of validation requested.This decision is either made automatically by the purchaser terminal 5according to predetermined rules set by the purchaser or manually bypresenting the request to the purchaser on monitor 9 and awaitingacceptance or refusal of the request from the purchaser via the keyboard11 or mouse 9. If the requested level of validation is not acceptable,then processing continues at step S11-9 where the purchaser terminal 5transmits a disapproval of the validation request to the vendor terminal21. The disapproval is received by the vendor terminal 21 at stepS11-11, following which the transaction process terminates.

On the other hand, if the requested level of validation is agreed, thenprocessing continues at step S11-13, at which step the purchaserterminal 5 transmits an approval of the validation request to the vendorterminal 21. Following receipt of the validation approval at stepS11-15, the vendor terminal 21 transmits a validation request(identifying the purchaser) to the registry 25 at step S11-17. At stepS11-19, the registry 25 receives the validation request from the vendorterminal 21 and at step S11-21 transmits the appropriate validation databack to the vendor terminal 21. The validation data is received by thevendor terminal 21 at step S11-23. Processing then proceeds as describedabove with reference to FIG. 8 such that the processing of steps S11-25to S11-33 corresponds to the processing of steps S7-11 to S7-19.

Another alternative to the processing of FIG. 8 is shown in FIG. 13. Inthis Figure, validation of the purchaser is performed at the registry 25but the purchaser terminal 5 is given no notice that the vendor terminal21 is to receive validation data from the registry 25. It is assumed inthe following description that the registry 25 and the vendor smart-card23 have already established a secure session by means of a processsimilar to the one described with reference to FIG. 7 above.

At step S12-1, the level of validation required is determined as in stepS7-1. At step S12-3, the vendor terminal 21 transmits to the registry 25a request for validation of the purchaser, which request is received bythe registry 25 at step S12-5. At step S12-7, the registry 25 transmitsthe validation data, which is then received by the vendor terminal 21 atstep S12-9. Processing then continues as for FIG. 8 with the processingof steps S12-11 to S12-19 corresponding to the processing of steps 7-11to steps 7-19.

A further method of validation will now be described with reference toFIG. 14. In this Figure it is the vendor which is being validated,however it should be understood that all methods of validation can beused to validate either the purchaser or the vendor or both. It isassumed in the following description that the registry 25 and the vendorsmart-card 23 have established a secure session and that the registry 25and the purchaser smart-card 3 have established a secure session bymeans of processing similar to that described with reference to FIG. 7above.

At step S13-1, the level of validation required is determined as forstep S8-1. At step S13-3, the purchaser terminal 5 transmits to theregistry 25 a request for validation of the vendor. Following receipt ofthe validation request by the registry 25 at step S13-5, the registry 25transmits to the vendor terminal 21 at step S13-7 a request forpermission to validate. The request is received at step S13-9 by thevendor terminal 21, and at step S13-11 it is decided whether to agree tothe level of validation requested in substantially the same manner asdescribed above with reference to FIG. 12. If the level of validation isnot agreed to then processing continues at step S13-13 where the vendorterminal 21 transmits a disapproval of the validation request to theregistry 25, following which the registry 25 receives the validationdisapproval at step S13-15. The transaction processing then ends.

On the other hand, if it is decided at step S13-11 that the level ofvalidation requested is agreed, then at step S13-17, the vendor terminal21 transmits a validation approval to the registry 25, which approval isreceived by the registry 25 at step S13-19. At step S13-21, the registry25 then transmits the validation data to the purchaser terminal 5 whichreceives the validation data at step S13-23. Following this, theprocessing continues as in FIG. 9 with the processing of steps S13-25 toS13-33 corresponding to the processing of step S8-11 to S8-19.

It is also possible for payment to take place in a number of differentways. For example, as mentioned above, the registry 25 may hold accountcards 33 p, 33 v on behalf of users of the payment system in asmart-card server 27. The presence of these account cards make itpossible for a prospective purchaser to have a large volume of fundsavailable to spend using the payment system without having to have thosefunds tied into the card which they carry, which card could be lost orstolen thereby denying the user access to those funds. It is thereforepossible that a purchaser may wish to make a payment from his or heraccount card 33 p or a vendor may wish to have a payment made to his orher account card 33 v. If such a payment is to take place, then thiswill be agreed between the parties before payment is made. If thepurchaser or the vendor decides to make payment from or to receivepayment from a registry smart-card 33, then the purchaser or the vendorsmart-card is informed of this and in response, it provides accountdetails of the appropriate registry smart-card 33, from its registrydata store 82. This information is then transmitted to the othersmart-card so that the appropriate secure session can be establishedbetween the other smart-card and the registry smart-card. Examples ofthese will now be described with reference to FIGS. 14 to 16.

Referring now to FIG. 15, there will be described payment and receiptingsteps to replace those described above with reference to FIG. 11 where apurchaser pays from funds held on their smart-card 3 to a registryaccount smart-card 33 v held on the vendors behalf. It is assumed in thefollowing description that the vendor registry account card 33 v and thevendor smart-card 23 have already established a secure session and thatthe vendor registry account card 33 v and the purchaser smart-card 3have already established a secure session by means of processing similarto that described with reference to FIG. 7 above.

At step S14-1, the vendor smart-card 23 transmits to the purchasersmart-card 3 a request for payment, which request is received at stepS14-3. At step S14-5, the purchaser smart-card 3 transmits theappropriate payment to the vendor account card 33 v at the vendoraccount card 33 v registry 25, which payment is received by the vendoraccount card 33 v at step S14-7. At step S14-9, the vendor account card33 v then transmits to the vendor smart-card 23 an acknowledgement thatthe payment has been made which acknowledgement is received at stepS14-11 by the vendor smart-card 23. The receipting process now continuesas in FIG. 11 with the processing of steps S14-13 to S14-25corresponding to the processing of steps S10-9 to S10-21.

Referring now to FIG. 16, there will be described a method of payment tothe vendor's smart-card 23 from the purchaser's registry account card 33p. It is assumed in the following description that the purchasersmart-card 3 has already transmitted account details of the purchaser'sregistry account card 33 p to the vendor smart-card 23, that theregistry account card 33 p and the vendor smart-card 23 have establisheda secure session and that the purchaser registry account card 33 p andthe purchaser smart-card 3 have already established a secure session bymeans of processing similar to that described with reference to FIG. 7above.

At step S15-1, the vendor smart-card 23 requests payment from thepurchaser smart-card 3. Following receipt of the request for payment bythe purchaser smart-card 3 at step S15-3, the purchaser smart-card 3transmits, at step S15-5, to the purchaser's registry account card 33 p,an instruction to make the payment. At step S15-7, the registry accountcard 33 p receives the payment instruction and at step S15-9, ittransmits the payment to the vendor smart-card 23. The payment isreceived by the vendor smart-card 23 at step S15-11, following which thereceipting procedure proceeds as in FIG. 11, whereby the processing ofsteps S15-13 to steps S15-25 corresponds to the processing of stepsS10-9 to S10-21.

Referring now to FIG. 17, there will be described the processing wherepayment is made from the purchaser's registry account card 33 p to thevendor's registry account card 33 v. It is assumed in the followingdescription that the purchaser smart-card 3 and the vendor smart-card 23have received details of the other's registry account cards 33 p,33 v;that the two registry account cards 33 p and 33 v have alreadyestablished a secure session between each other; that the purchaserregistry account card 33 p and the purchaser smart-card 3 have alreadyestablished a secure session between each other; and that the vendorregistry account card 33 v and the vendor smart-card 23 have alreadyestablished a secure session between each other.

At step S16-1, the vendor smart-card 23 transmits a request for paymentto the purchaser smart-card 3, which request is received at step S16-3.At step S16-5, the purchaser smart-card 3 transmits a paymentinstruction to the purchaser's registry account card 33 p, which paymentinstruction is received at step S16-7. The purchaser account card 33 pthen effects the payment to vendor's registry account card 33 v at stepS16-9. At step S16-11, the vendor's registry account card 33 v transmitsa payment acknowledgement to the vendor smart-card 23 whichacknowledgement is received at step S16-13. Thereafter, the receiptingprocess between the purchaser smart-card 3 and the vendor smart-card 23continues as in FIG. 11, with the processing of steps S16-15 to S16-27corresponding to the processing of steps S10-9 to S10-21.

A further optional feature of the payment system described in any of theabove embodiments is that a smart-card for use with the payment systemmay hold funds in a number of different currencies. It will be possibleto load funds onto a purchaser's smart-card 3 or registry account card33 p in the required currency or it would be possible to convert fundsheld on the card. Conversion between currencies could take place on aparticular user card 3 or 23 or, as would be preferable from a fraudcontrol point of view, conversion could be undertaken on a user'sregistry account card 33 under the control of the registry 25 to preventfraudulent currency creation. The process of currency conversation doesnot entail the actual conversion of one currency into another, rather itimplies debiting an amount in one currency and crediting the equivalentamount in another currency. The implications of this are twofold;

-   -   1) external (off card) funds must be held in the currency to be        supplied;    -   2) the exchange rate will be externally (off card) supplied.

An example of how conversion of funds within a registry account card 33could be accomplished by a user will now be described with reference toFIG. 18.

Before the currency conversion process may commence, a secure sessionbetween the user's own card 3 or 23 and the registry card 33 p or 33 v,respectively must be established. This is achieved in the same manner asdescribed above with reference to FIG. 6. Thus steps S17-1 to S17-19correspond to steps S6-9 to S6-27 in that the user card 3 transmits itspublic key to the registry card which, following receipt of the usercard public key, generates a registry session ID in the same manner asthe session IDs were generated with reference to FIG. 7 above. Theregistry smart-card 33 p or 33 v then encrypts the registry session IDwith the cardholder public key and transmits the encrypted session IDand the registry public key back to the user smart-card 3. The usersmart-card 3 then generates a user session ID, encrypts it with theregistry public key and transmits the encrypted user session ID to theregistry. Once the registry smart-card 33 p or 33 v has received theencrypted user session ID, it transmits a message to the user card 3stating that the session ID was received successfully. Following this,at step S17-21 the cardholder terminal 5 transmits a request forconversion of account funds from a first currency to a second currencywhich request is received by the registry 25 at step S17-23. At stepS17-25, the registry 25 performs a check to determine whether theaccount card 33 holds sufficient funds to perform the currencyconversion. If it is determined that sufficient funds are not present,then processing continues at step S17-27, where the registry 25transmits to the cardholder terminal 5 that there are insufficient fundsin the account card 33 p to perform a conversion. This is received bythe cardholder terminal 5 at step S17-29, following which the conversionprocedure terminates. On the other hand, if it is determined at stepS17-25 that there are sufficient funds in the account to perform thecurrency conversion then at step S17-31 the funds are converted and atstep S17-33 the registry 25 transmits to the cardholder terminal 5 aconfirmation that the funds have been converted and a note of the fundstotals in the relevant currencies available on the registry account cardfollowing the conversion. This is received by the card holder terminal 5at step S17-35, following which the currency conversion procedureterminates.

A further feature which may be applied to the payment system accordingto any of the described embodiments is that transaction logging may beundertaken. At the end of a given transaction, both the vendor andpurchaser will have stored in the transaction log store 80 of theirrespective smart-cards 3, 23 a record of all of the data transferredduring the transaction. This record will include the goods or servicesspecified, any validation data concerning the purchaser or vendor, anydelivery data and payment data. Each party to the transaction thereforehas a complete record of that transaction. A limited number of suchtransaction records may be held by the smart-card 3, 23 to provide ashort-term transaction log. However, due to the memory limitations ofsmart-cards, it is not likely to be possible for the smart-card to storea complete log of all transactions in which the particular smart-card 3,23 is involved. Therefore, the smart-cards are programmed to allow thetransaction records to be copied from the transaction log store 80 intoa full transaction log within a personal computer or the like. Forexample, a vendor may set up an automatic process through their usualvending terminal such that at the completion of any transaction, a copyof that transaction record is made on a central transaction log heldwithin the vendor terminal or in a further terminal which is connectedto the vendor terminal. A purchaser may for example, have a homecomputer comprising a smart-card reader into which the user smart-card 3may be inserted such that records of purchases made using the smart-card3 may be transferred to a log on the home computer. In addition, theregistry 25 may be configured to automatically save details of alltransactions in which it is involved in order to provide a centralisedaccountability for the payment system.

In the above embodiments, different levels of validation were described.Some practical trading examples will now be described that illustratehow these different levels of validation would be used.

VALIDATION LEVEL EXAMPLES Internet Trading Example 1

In this example, a user of the payment system wishes to purchase weatherforecast data from the UK Meteorological Office. The purchaser knows heis at the Meteorological Office website and trusts them to deliver therequested information. There is no reason for the purchaser to carry outany further checking on the vendor. The Meteorological Office does notcare who the purchaser is or where they are located. The information tobe purchased is not restricted in any way. In addition, theMeteorological Office will collect payment from the purchaserssmart-card before shipping the requested information. So the vendorrequires no further information about the purchaser and an immediateanonymous trade can take place subject to both parties indicating theirsatisfaction with the price and terms of trade.

Internet Trading Example 2

In this example, the purchaser wishes to buy videos from an internetdiscount store. In this case the value of the trade will be low butchecking is required by both parties. The vendor will wish to assureitself that the purchaser is of a suitable age to purchase the videosrequested, while the purchaser will wish to validate the credentials andlocation of the vendor to ensure that the vendor will not simply takethe purchaser's money and disappear, never delivering the goods.

The vendor could simply ask a purchaser for their age and address butthere would be no support for this information, which therefore couldnot be trusted. The vendor would therefore check the credentials of thepurchaser with the registry 25 and if the purchaser was not registeredor refused to permit the information to be released, the vendor couldrefuse to sell the products to this purchaser. If the information wereprovided, only a low confidence level would probably be required and theregistry 25 would provide no warranties or guarantees.

The purchaser would wish to be assured that the vendor can be trusted.To achieve this, the purchaser would check that the vendor had aregistry account and that the vendor would allow the registry 25 torelease/confirm the address of the vendor. Only under thesecircumstances would the purchaser agree to make the trade.

When both parties are satisfied with the information supplied, the saleprice, the transaction charges and the terms of trading, the sale wouldbe completed and value transferred. In subsequent trades between the twoparties, it is likely that the purchaser will have built up a level oftrust in the vendor such that the purchaser will not seek any validationfrom the registry.

Internet Trading Example 3

This example concerns the purchase of fine art. In this circumstance agreat deal of checking and validation will be required. Even though thevendor will be paid immediately, the vendor may need to verify thenationality and domicile of a purchaser. The vendor may also wish toavoid being part of a possible money laundering exercise and willtherefore seek the most exhaustive credentials concerning a purchaserwith the highest level of confidence.

The purchaser will also need to have more guarantees than simply thecredentials of the vendor. Since the fine art cannot be authenticateduntil it is shipped (or the benefit of using the internet will be lost),and since the goods may be damaged in transit, the purchaser may seek acash back guarantee from the smart-card registry 25. For this purpose,the registry 25 may be underwritten to supply such a guarantee with theproperly authenticated vendors but of course is likely to levy a hightransaction charge for this service.

Once all parties have agreed to the levels of confidence they have beengiven, agreed prices, transaction charges and terms and conditions, thetrade may be completed. Given the high value of the deal, it is likelythat payment will be made from an account card held by the registry onthe purchaser's behalf, rather than his or her personal card. Inaddition, it may be possible for the registry operator to function as acredit providing service such that users of the payment system may beable to borrow money from the registry to be paid back at a later dateas with a traditional credit card 25.

Real World Trading Example 1

For the purpose of purchasing goods such as a newspaper the smart-cardof the payment system according to the present invention may be used asa “traditional” electronic purse at any shop accepting the card. To makea newspaper purchase the cardholder will simply use his or her card inan anonymous manner to make the purchase using a purchaser smart-cardreader provided within the shop.

Real World Trading Example 2

For the purchase of a larger value item such as a television, thepurchaser may have sufficient value on their personal card to makepayment or they may indicate their desire to pay from the registryaccount card in much the same way as a traditional bank debit cardpayment. In either event, the vendor will wish to validate thecredentials of the purchaser to check that the card has not been lost orstolen and that a registry account is not being fraudulently used. Inthe case of account payment, the vendor will also take payment from theregistry 25.

For this purpose the vendor will need a simple smart-card terminalcapable of connectivity either directly to the registry or via theinternet. Such terminal may be similar to the bank/credit card terminalcurrently in use for debit and credit card payments. Since the purchaseris physically in the vendor's shop it is unlikely that they will seekany further accreditation of the vendor, however this is alwayspossible. For example, the purchaser may wish to obtain guarantees aboutthe delivery date and goods quality for purpose made goods. To achievethis, the purchaser will make use of a vendor's terminal to contact theregistry and seek the necessary guarantees. Once all terms have beenagreed, the purchaser can authorise payment to be made in exactly thesame way as in the case with internet trading.

Real World Trading Example 3

Booking or purchasing a ticket from an unattended terminal is the sameas internet trading. For ticket purchases, it will be possible for aphysical paper ticket to be issued via the terminal, for a ticket to bedelivered to the vendor following the purchase transaction at theterminal or for an electronic ticket to be written to the purchaser'ssmart-card. This is possible because a smart-card is not restricted toholding programs and/or data for a single purpose but may have a numberof separate application entities on the same card. In particular,technologies such as Sun Microsystems Inc's JavaCard™ technology allowapplications to be written to a smart-card at any time. Thus the user ofa smart-card equipped with programming to perform processing to enableit to participate in the payment system of the present invention coulddecide that the ability to have electronic tickets written to his or hercard would be useful and therefore arrange for software to enable thatfunction to be written to his or her card at any time.

Although it has been described above with reference to FIGS. 1 to 16that the purchaser terminal 5 and the vendor terminal 21 are physicallyseparated and connected via the internet, it is possible that acardholder may wish to use their smart-card at the vendor's location.This situation is discussed in the above trading examples, and is shownin a simplified form in FIG. 19. In FIG. 19, the vendor terminal 21having a monitor 9, a keyboard 11 and a mouse 13, which terminal may becombined with or a part of a shop cash register or till, is equippedwith a smart-card reader 31 into which the vendor smart-card 23 may beinserted. For security purposes it may be preferable for the smart-cardslot 31 to be physically separated from the terminal 21 and connectedvia a cable or other data communications link because the terminal 21may be in an area accessible to customers and having the smart-card 23in such a location could be perceived to be a security risk. As before,the vendor terminal 21 is equipped with a modem 15 by means of which itmay communicate with the registry terminal 25 by transmitting signals 17via the internet 19 or by a telephone line.

Also connected to the vendor terminal 21 is a user smart-card reader 34into which the user smart-card 3 may be inserted by a purchaser when apurchase is to be made using the payment system of the presentembodiment. In such circumstances, there is obviously no need forcommunication between the purchaser smart-card 3 and the vendorsmart-card 23 to take place via the internet and thus the same processas described above with reference to flow diagrams 4 to 16 may beperformed as shown but with communication between the cards 3 and 23taking place via the cables connecting the user smart-card reader 34 tothe vendor smart-card reader 31.

It should be noted that in the above-described arrangement, the vendorand purchaser smart-cards still create a secure session to wrap thetransaction to provide full transaction accountability and traceability,to provide a secure channel between the cards to transfer funds, and toenable data to be certified, all as described above.

In the event that either the purchaser or the vendor should wish tovalidate the other party at the registry or make payment from or receivepayment to a registry account card this may be achieved using theinternet connection to the registry terminal 25.

Referring to FIG. 20, there is shown a block diagram of the mainfunctional components of the vendor terminal 21 used in this embodiment.As before, a CPU making use of a working memory 43 to performinstructions stored in software store 47, a keyboard and mouse interface49 to receive input from a user and a monitor interface 51 to outputinformation to a user are present and are connected via a data bus 45.Also connected via the data bus 45 is the modem 55 for communicationwith the registry terminal 25 via the internet 19 or telephone line. Thevendor smart-card reader interface 59 and the purchaser smart-cardreader 61 are also connected to the data bus 45.

Although it has been described above that the various terminalscommunicate with one another via the internet, the terminals may beconnected together via a Local Area Network (LAN) or a Wide Area Network(WAN). In addition, it is possible that the terminals could perform aso-called “tunnelling” operation to create a Virtual Private Network(VPN) between the terminals across the internet, or a direct dialtelephone link between the terminals may be used.

Although it has been described above that where particular validationdata or particular delivery terms are decided to be unacceptable thetransaction process terminates, further negotiations between the twoparties could be undertaken to resolve such situations. For example, aprospective purchaser may select a product and request next daydelivery, but then decide that the cost for next day delivery is morethan he or she is willing to pay. It could be made possible for theprospective purchaser to request to be offered a cheaper deliveryservice which they might then accept.

Although it has been described above, particularly with reference toFIG. 5, that validation of a purchaser is performed before validation ofthe vendor, it is not essential that the validations are performed inthis order and therefore validation of a vendor could be performedbefore validation of the purchaser or even at the same time.

Although, it has been described above with reference to FIG. 5 that astep is taken to determine whether or not to validate the purchaser orvendor followed by which the level of validation required is determined,it is possible that these two steps could be combined into one singleoperation, wherein if no validation is required the steps to achievevalidation could be omitted.

Although it is described above with reference to FIG. 9 that a purchaseris required to enter delivery data when required, it is possible thatsuch data could be stored within the purchaser terminal or purchasersmart-card and the transfer of such data to the purchaser terminal couldbe achieved without reference to the purchaser.

Although it is described above that the registry 25 stores validationdata, it is possible that the validation data could be stored on theregistry account card 33 v, 33 p.

Although it is described above that a single registry 25 is present, itis possible that a number of registries could exist. In this case itwould become necessary to establish which registry should be queried toreceive validation data from the party to be validated. For simplicity,this information is preferably stored on the party's smart-card.

Although it has been described with reference to FIG. 4 that deliverydata is transmitted after validation, it is entirely possible to includedelivery data within the validation data. This is a favourablemodification to the above system as it is likely that validation datawould include address data and therefore duplication of data can bereduced and thus transaction processing time can be reduced. Thedelivery data would always be transmitted after establishing thesession, but need not necessarily be encrypted.

Although it has been described above with reference to FIG. 7 that aspecific security arrangement is used to establish the secure session,it is to be noted that the security algorithms used by the smart-cardsand the operation of the security engine on the smart-cards does notmatter, provided that an asymmetric key system of the type used inpublic key encryption is used. Examples of encryption schemes whichcould be used are RSA type algorithms and elliptic curve techniques.However, it is not an open public key system requiring a certificationauthority to validate ownership, rather it is a private system knownonly to the smart-cards themselves.

Although it has been described above with reference to FIG. 7 that alldata passing between the terminals (and the registry) will be encryptedby the smart-card 3, 23, 33 in the terminal (or registry) beforetransmission, it is not necessary for all data to be encrypted. Only thedata which the parties do not wish to be general public knowledge (whichcould happen if the data were intercepted) and the data which requirescertification as to its origin and validity (such as validation data),and therefore requires a “digital signature”, need be encrypted. Asthose skilled in the art will appreciate, the function of the securesession IDs of digitally signing the transmitted data to certifyvalidity and origin could be achieved by methods other than thatdescribed above. In particular, a number of techniques of so-called“digital water-marking” exist, which could be used to certify the data,or encryption keys themselves could be used as signatures.

Although it has been described above that the various terminals havespecific components and arrangements, it is sufficient for theperformance of the embodiments that any stand alone terminal has a cardreader, a means for presenting data to and requesting data from a user,means for receiving user input and means for communicating with otherterminals. Thus it is not necessary for the terminal to be a desk-topcomputer. It is possible that terminals may take the form of railway,airline or bus ticket vending machines, public information booths orterminals, theatre or cinema ticketing booths, shop tills, portablecomputers, hand-held computers and information appliances, telephonesand tourist attraction entry gates, for example. As those skilled in theart will appreciate, the present invention can be used not only from apurchaser's own home terminal but from terminals in so-called internetcafes and in other public terminals.

Although it has been described above with reference to FIGS. 11 to 16that the registry or a registry account card is included in the securesession before a request for validation data or payment is made to theregistry or account card, it is possible that the registry or registryaccount card will only be included in the secure session when validationdata or payment is requested.

Although it has been described above that a user would hold funds ontheir user smart-card and may hold further funds on their registryaccount card, it is possible to operate the entire system in the mannerof a credit card system whereby a user holds no funds on their ownsmart-card or on their registry account card, but every time they wishto make a purchase requesting payment from the registry account, andfunds being provided to the registry account by the registry on a creditbasis with the money supplied as credit to be repaid by the useraccording to predetermined practices. It is also possible for the systemto be operated in a combination of a stored cash and credit based systemwhereby a user may store small amounts of cash on their personalsmart-card or on their registry account card, but for large purchasesmake use of a credit arrangement with the registry provider. Such asystem would address the problem of previous smart-card systems wherebyfunds held on the card are “locked in” to the card.

The smart-cards used to implement the present invention may use anystandard interface. There is an International Standard (ISO7816-3) whichgoverns the so-called contact interface where the microchip on thesmart-card interfaces with a reader by means of physical contactsbetween the microchip on the smart-card and the reader. There is afurther International Standard (ISO14443) which governs the so-calledcontactless interface. In this interface, the microchip on thesmart-card and the reader have no physical connection, all communicationbetween the reader and the smart-card, including supply of power to thesmart-card, is performed using radio transmissions. It is also possibleto implement the invention using a smart-card capable of using both ofthe above interface types.

As described above, the smart-cards 3,23,33 may be implemented usingmulti-programmable technologies such as Sun Microsystems Inc's JavaCard™technology. It is therefore possible for a person or organisationalready possessing a smart-card conforming to such a multi-programmabletechnology to have software to enable the smart-card as a smart-card3,23,33 according to any of the above embodiments loaded onto theirsmart-card. Such software loading could be performed by an authoritysuch as a registry operator, or the software could be transmitted to thesmart-card owner via the internet or similar connection, or on a storagemedium such as a floppy disk or CD-ROM for the smart-card owner to useto load the software onto the smart-card themselves.

Although it has been described above that the session IDs should begenerated using a time stamp, a random number, a terminal ID and asmart-card ID, it is not necessary that the session ID be generated inthis manner for the successful operation of the embodiments. As oneskilled in the art would appreciate, any method of generating a new,unique session ID for each transaction that a particular smart-card3,23,33 is involved in, could be used. This method could involve usingless than all of the above parts of the session ID described in theabove embodiment, or other values such as account holder identifiers ora transaction counter could be used.

1. An electronic transaction payment system comprising: a vendorterminal associated with a vendor who provides goods or services to apurchaser; a vendor smart-card; a vendor smart-card reader fortransmitting data to and receiving data from said vendor smart-card; apurchaser smart-card; and a purchaser smart-card reader for transmittingdata to and receiving data from said purchaser smart-card; wherein saidvendor terminal comprises: (i) means for processing requests for vendorgoods or services from said purchaser; (ii) means for generating costdata identifying the cost of requested goods or services; (iii) meansfor interfacing with said vendor smart-card reader; (iv) means forinterfacing with said purchaser smart-card reader; and (v) means fortransmitting the cost data to said purchaser smart-card via saidpurchaser smart-card reader interface; wherein said purchaser smart-cardcomprises: (i) means for receiving said cost data from said vendorterminal; (ii) means for encrypting payment data to be transmitted tosaid vendor smart-card; and (iii) means 25 for outputting the encryptedpayment data for transmission to said vendor smart-card; and whereinsaid vendor smart-card comprises: (i) means for receiving said encryptedpayment data from said purchaser smart-card; and (ii) means fordecrypting said encrypted payment data received from said purchasersmart-card to obtain payment for the requested goods or services.
 2. Asystem according to claim 1, wherein said purchaser smart-card furthercomprises means for digitally signing said payment data using apurchaser digital signature and wherein said vendor smart-card furthercomprises means for reading the digital signature applied to the paymentdata to establish the origin of the payment.
 3. A system according toclaim 2, wherein said vendor smart-card further comprises means forgenerating receipt data describing the goods or services requested andthe payment obtained from said payment data; means for digitally signingsaid receipt data using a vendor digital signature; and means foroutputting the signed receipt data for transmission to said purchasersmart-card; and wherein said purchaser smart-card further comprisesmeans for receiving said signed receipt data and means for reading thevendor digital signature applied to the receipt data to establish theorigin of the receipt.
 4. A system according to claim 3, wherein atleast one of each said digital signatures is generated using a timestamp.
 5. A system according to claim 3, wherein at least one of eachsaid digital signatures is generated using a random number.
 6. A systemaccording to claim 3, wherein at least one of each said digitalsignatures is generated using a smart-card identifier.
 7. A systemaccording to claim 3, wherein at least one of said digital signatures isgenerated using a terminal identifier.
 8. A system according to claim 3,wherein each of said digital signatures is different.
 9. A systemaccording to claim 3, wherein said digital signatures are the same. 10.An electronic transaction payment system according to claim 2, whereinsaid means for digitally signing said payment data comprises saidencrypting means; and said means for reading said purchaser digitalsignature comprises said decrypting means.
 11. A system according toclaim 1, wherein: said vendor terminal further comprises means forreceiving a request for data describing the vendor; and means foroutputting said request to said vendor smart-card; and said vendorsmart-card further comprises means for receiving said request for datadescribing the vendor; means for generating data describing the vendorin accordance with said request; and means for outputting the datadescribing the vendor to said vendor terminal.
 12. A system according toclaim 11, wherein said purchaser smart-card further comprises means forreceiving said data describing the vendor from said vendor smart-card;and means for determining whether said data describing the vendorconforms to a predetermined condition to determine whether said paymentdata should be generated for transmission to said vendor smart-card. 13.A system according to claim 1, comprising: a registry; a registrysmart-card; and a registry smart-card reader for transmitting data toand receiving data from said registry smart-card; wherein said registrycomprises: means for interfacing with said registry smart-card reader;and means for interfacing with said vendor terminal; wherein saidpurchaser smart-card further comprises means for outputting a requestfor data describing the vendor for transmission to said registrysmart-card; wherein said registry smart-card comprises: means forreceiving said request for data describing the vendor from saidpurchaser smart-card; means for generating data describing the vendor inaccordance with said request; and means for outputting the datadescribing the vendor for transmission to said purchaser smart-card; andsaid purchaser smart-card further comprises: means for receiving saiddata describing the vendor from said registry smart-card; and means fordetermining whether said data describing the vendor conforms to apredetermined condition to determine whether said payment data should begenerated for transmission to said vendor smart-card.
 14. A systemaccording to claim 1 wherein: said vendor terminal further comprisesmeans for receiving a request for data describing the purchaser; andmeans for outputting said request for transmission to said purchasersmart-card; and said purchaser smart-card further comprises: means datadescribing the for receiving said request for data purchaser; forgenerating data describing the purchaser in accordance with saidrequest; and means for outputting the data describing the purchaser fortransmission to said vendor terminal.
 15. A system according to claim14, wherein said vendor smart-card further comprises: means forreceiving said data describing the purchaser from said vendorsmart-card; and means for determining whether said data 30 describingthe purchaser conforms to a predetermined condition to determine whethersaid goods or services are to be provided to said purchaser or whethersaid payment data is to be accepted.
 16. A system according to claim 1,comprising: a registry; a registry smart-card; and a registry smart-cardreader for transmitting data 10 to and receiving data from said registrysmart-card; wherein said registry comprises means for interfacing withsaid registry smart-card reader; and means for interfacing with saidvendor terminal; wherein said vendor smart-card further comprises meansfor outputting a request for data describing the purchaser fortransmission to said registry smart-card; wherein said registrysmart-card further comprises: means for receiving said request for datadescribing the purchaser from said vendor smart-card; means forgenerating data describing the purchaser in accordance with saidrequest; and means for outputting the data describing the purchaser fortransmission to said vendor smart-card; and wherein said vendorsmart-card further comprises: means for receiving said data describingthe purchaser from said registry smart-card; and means for determiningwhether said data describing the purchaser conforms to the predeterminedcondition to determine whether said goods or services are to be providedto said purchaser 30 or whether said payment data is to be accepted. 17.A system according to claim 1, wherein said vendor smart-card furthercomprises a memory for storing an asymmetric encryption key paircomprising a vendor private key and a vendor public key; and means foroutputting said vendor public key for transmission to said purchasersmart-card, wherein said purchaser smart-card further comprises meansfor receiving said vendor public key; and is operable to encrypt saidpayment data using said vendor public key; and wherein said means fordecrypting said payment data in said vendor smart-card is operable todecrypt the payment data using the vendor private key.
 18. A systemaccording to claim 17 wherein said asymmetric encryption key pair aregenerated using an RSA algorithm.
 19. A system according to claim 17,wherein said asymmetric encryption key pair are generated using anelliptic curve algorithm.
 20. A system according to claim 1, whereinsaid purchaser smart-card reader interface comprises means forcommunication via a computer network.
 21. A system according to claim 1wherein said purchaser smart-card reader interface comprises means forcommunication via the Internet.
 22. A system according to claim 1comprising: a registry; a purchaser registry smart-card associated withthe purchaser; and a registry smart-card reader for transmitting data toand receiving data from said purchaser registry smart-card; wherein saidregistry comprises means for 10 interfacing with said registrysmart-card reader; means for interfacing with said vendor terminal;wherein said purchaser smart-card further comprises: means forgenerating instruction data, for instructing 15 said purchaser registrysmart-card to make a payment, to be transmitted to said vendorsmart-card; and means for outputting the instruction data fortransmission to said purchaser registry smart-card; wherein saidpurchaser registry smart-card further comprises means for receiving saidinstruction data from 20 said purchaser smart-card; means for generatingpayment data to be transmitted to said vendor smart-card; means forencrypting said payment data; and means for outputting the encryptedpayment data for transmission to said vendor smart-card; and whereinsaid vendor smart-25 card further comprises: means for receiving saidencrypted payment data from said purchaser registry smart-card.
 23. Asystem according to claim 1, further comprising: a registry; a vendorregistry smart-card; and a registry smart-card reader for transmittingdata to and receiving data from said vendor registry smart-card; whereinsaid purchaser smart-card further comprises means for outputting saidencrypted payment data for transmission to said vendor registrysmart-card; wherein said vendor registry smart-card comprises: means forreceiving said encrypted payment data from said purchaser smart-card;means for decrypting said encrypted payment data received from saidpurchaser smart-card to obtain payment for the requested goods orservices; means for generating acknowledgement data describing theobtained payment; and means for outputting said acknowledgement data fortransmission to said vendor smart-card; and wherein said vendorsmart-card further comprises means for receiving said acknowledgementdata from said 20 vendor registry smart-card.
 24. A system according toclaim 1, further comprising a purchaser terminal associated with thepurchaser, the purchaser terminal comprising: (i) means for generating arequest for vendor goods or services from said purchaser; (ii) means forinterfacing with said purchaser smart-card reader; (iii) means forinterfacing with said vendor terminal; and (iv) means for transmittingsaid purchaser requests to said vendor 30 terminal via said purchasersmart-card.
 25. A system according to claim 24, wherein data transmittedbetween said purchaser terminal and said vendor terminal is encryptedbefore transmission by the respective smart-cards.
 26. An electronictransaction payment system comprising: a vendor terminal associated witha vendor who provides goods or services to a purchaser; a vendorsmart-card; a vendor smart-card reader for transmitting data to andreceiving data from said vendor smart-card; a purchaser smart-card; anda purchaser smart-card reader for transmitting data to and receivingdata from said purchaser smart-card; wherein said vendor terminalcomprises: (i) means for processing requests for vendor goods orservices from said purchaser; (ii) means for generating cost dataidentifying the cost of requested goods or services; (iii) means forinterfacing with said vendor smart-card reader; (iv) means forinterfacing with said purchaser smart-card reader; and (v) means fortransmitting the cost data to said purchaser smart-card via saidpurchaser smart-card interface; wherein said purchaser smart-cardcomprises: (i) means for receiving said cost data from said vendorterminal; (ii) means for digitally signing payment data to betransmitted to said vendor smart-card; (iii) means for outputting thesigned payment data for transmission to said vendor smart-card; whereinsaid vendor smart-card comprises: (i) means for receiving said signedpayment data from said purchaser smart-card to obtain payment for therequested goods or services; (ii) means for reading the digitalsignature applied to the payment data to establish the origin of thepayment; (iii) means for generating receipt data describing the goods orservices and the payment obtained from said payment data; (iv) means fordigitally signing said receipt data; and (v) means for outputting 10 thesigned receipt data for transmission to said purchaser smart-card,wherein said purchaser smart-card further comprises: (iv) means forreceiving said signed receipt data; and (v) means for reading thedigital signature applied to the receipt data to establish the origin ofthe receipt.
 27. An electronic transaction payment system comprising: avendor terminal associated with a vendor who provides goods or servicesto a purchaser; a vendor smart-card; a vendor smart-card reader fortransmitting data to and receiving data from said vendor smart-card; apurchaser smart-card; and a purchaser smart-card reader for transmittingdata to and receiving data from said purchaser smart-card; wherein saidvendor terminal comprises: (i) means for processing requests for vendorgoods or services from said purchaser; (ii) means for generating costdata identifying the cost of requested goods or services; (iii) meansfor interfacing with said vendor smart-card reader; (iv) means forinterfacing with said purchaser smart-card; and (v) means fortransmitting the cost data to said purchaser smart-card via saidpurchaser smart-card reader interface; wherein said purchaser smart-cardcomprises: (i) means for receiving said cost data from said vendorterminal; (ii) means for generating a request for data describing thevendor; and (iii) means for outputting the request for data describingthe vendor for transmission 10 to said vendor smart-card; wherein saidvendor smart-card comprises: (i) means for receiving said request fordata describing the vendor from said purchaser smart-card; (ii) meansfor generating data describing the vendor in accordance with saidrequest; and (iii) means for outputting the data describing the vendorfor transmission to said purchaser smart-card; wherein said purchasersmart-card further comprises: (iv) means for receiving said datadescribing the vendor from said vendor smart-card; (v) means fordetermining whether said data describing the vendor conforms to apredetermined condition; (vi) means for, if said data describing thevendor conforms to said predetermined condition, generating payment datato be transmitted to said vendor smart-card; and (vii) means foroutputting the payment data for transmission to said vendor smart-card;and wherein said vendor smart-card further comprises: (iv) means forreceiving said payment data from said purchaser smart-card to obtainpayment for requested goods or services.
 28. An electronic transactionpayment system comprising: a vendor terminal associated with a vendorwho provides goods or services to a purchaser; a vendor smart-card; avendor smart-card reader for transmitting data to and receiving datafrom said vendor smart-card; a purchaser smart-card; and a purchasersmart-card reader for transmitting data to and receiving data from saidpurchaser smart-card; wherein said vendor terminal comprises: (i) meansfor processing requests for vendor goods or services from saidpurchaser; (ii) means for generating cost data identifying the cost ofrequested goods or services; (iii) means for interfacing with saidvendor smart-card reader; (iv) means for interfacing with said purchasersmart-card reader; and (v) means for transmitting the 20 cost data tosaid purchaser smart-card via said purchaser smart-card readerinterface; wherein said purchaser smart-card comprises: (i) means forreceiving said cost data from said vendor terminal; wherein said vendorsmart-card comprises: (i) means for generating a request for datadescribing the purchaser; and (ii) means for outputting the request fordata describing the purchaser for transmission to said purchasersmart-card; wherein said purchaser smart-card further comprises: (ii)means for receiving said request for data describing the purchaser fromsaid vendor smart-card; (iii) means for generating data describing thepurchaser in accordance with said request; and (iv) means for outputtingthe data describing the purchaser for transmission to said vendorsmart-card; wherein said vendor smart-card further comprises: (iii)means for receiving said data describing the 10 purchaser from saidpurchaser smart-card; (iv) means for determining whether said datadescribing the purchaser conforms to a predetermined condition; (v)means for, if said data describing the purchaser conforms to said 15predetermined condition, generating acceptance data to be transmitted tosaid purchaser smart-card; and (vi) means for outputting the acceptancedata for transmission to the purchaser smart-card; and wherein saidpurchaser smart-card further comprises: (v) means for receiving saidacceptance data from said vendor smart-card; (vi) means for generatingpayment data to be transmitted to said vendor smart-card; and (vii)means for outputting the payment data for transmission to said vendorsmart-card; and wherein said vendor smart-card further comprises: (viii)means for receiving said payment data from said purchaser smart-card toobtain payment for the requested goods or services.
 29. An electronictransaction payment system comprising: a vendor terminal associated witha vendor who provides goods or services to a purchaser; a vendorsmart-card; a vendor smart-card reader for transmitting data to andreceiving data from said vendor smart-card; a purchaser smart-card; anda purchaser smart-card reader for transmitting data to and receivingdata from said purchaser smart-card; wherein said vendor terminalcomprises: (i) means for processing requests for vendor goods orservices from said purchaser; (ii) means for generating cost dataidentifying the cost of requested goods or services; (iii) means forinterfacing with said vendor smart-card 15 reader; (iv) means forinterfacing with said purchaser smart-card; and (v) means fortransmitting the cost data to said purchaser smart-card via saidpurchaser smart-card reader interface; wherein said purchaser smart-cardcomprises: (i) means for receiving said cost data from said vendorterminal; (ii) means for generating a request for data describing thevendor; and (iii) means for outputting the request for data describingthe vendor for transmission to said vendor smart-card; wherein saidvendor smart-card comprises: (i) means for receiving said request fordata describing the vendor from said purchaser smart-card; (ii) meansfor receiving data describing the vendor in accordance with saidrequest; and (iii) means for outputting the data describing the vendorfor transmission to said purchaser smart-card; wherein said purchasersmart-card further comprises: (iv) means for receiving said datadescribing the vendor from said vendor smart-card; (v) means foroutputting said data describing said vendor to the purchaser; (vi) meansfor receiving an indication whether or not said data describing thevendor is acceptable to the purchaser; and (vii) means for, if said datadescribing the vendor is acceptable, causing payment data to betransmitted to said vendor smart-card; and wherein said vendorsmart-card further comprises: (iv) means for receiving said payment datato obtain payment for the requested goods or services.
 30. An electronictransaction payment system comprising: a vendor terminal associated witha vendor who provides goods or services to a purchaser; a vendorsmart-card; a vendor smart-card reader for transmitting data to andreceiving data from said vendor smart-card; a purchaser smart-card; anda purchaser smart-card reader for transmitting data to and receivingdata from said purchaser smart-card; wherein said vendor terminalcomprises: (i) means for processing requests for vendor goods orservices from said purchaser; (ii) means for generating cost dataidentifying the cost of requested goods or services; (iii) means forinterfacing with said vendor smart-card reader; (iv) means forinterfacing with said purchaser smart-card reader; and (v) means fortransmitting the cost data to said purchaser smart-card via saidpurchaser smart-card reader interface; wherein said purchaser smart-cardcomprises: (i) means for receiving said cost data from said vendorterminal; wherein said vendor smart-card comprises: (i) means forgenerating a request for data describing the purchaser; and (ii) meansfor outputting the request for data describing the purchaser fortransmission to said purchaser smart-card; wherein said purchasersmart-card further comprises: (ii) means for receiving said request fordata describing the purchaser from said vendor smart-card; (iii) meansfor receiving data describing the purchaser in accordance with saidrequest; and (iv) means for outputting the data describing the purchaserfor transmission to said vendor smart-card; wherein said vendorsmart-card further comprises: (iii) means for receiving said datadescribing the purchaser from said purchaser smart-card; (iv) means foroutputting said data describing the purchaser to the vendor; (v) meansfor receiving an indication whether or not said data describing thepurchaser is acceptable to the vendor; (vi) means for, if said datadescribing the purchaser is acceptable, generating acceptance data to betransmitted to said purchaser smart-card; and (vii) means for outputtingthe acceptance data for transmission to the purchaser smart-card; andwherein said purchaser smart-card further comprises: (v) means forreceiving said acceptance data from said vendor smart-card; (vi) meansfor generating payment data to be transmitted to said vendor smart-card;and (vii) means for outputting the payment data for transmission to saidvendor smart-card; and wherein said vendor smart-card further comprises:(viii) means for receiving said payment data from said purchasersmart-card to obtain payment for the requested goods or services.
 31. Asmart-card programmed to be able to function as a purchaser smart-cardaccording to claim
 1. 32. A smart-card programmed to be able to functionas a vendor smart-card according to claim
 1. 33. A smart-card programmedto be able to function as a registry smart-card according to claim 13.34. A smart-card comprises: means for interfacing with a card reader;means for receiving details of a new transaction from an externalterminal via said interfacing means and said card reader; means forgenerating a unique session ID for the new transaction; means forstoring the generated session ID; means for receiving message datarelating to the new transaction from the external terminal via said cardreader and said interfacing means; means for tagging the receivedmessage data by appending the stored session ID to the message data; andmeans for outputting the tagged message data to said external terminalvia said interface means and said card reader.
 35. A smart-cardaccording to claim 34, further comprising means for encrypting saidtagged message data.
 36. A smart-card according to claim 34, furthercomprising means for receiving a session ID generated by anothersmart-card involved in the new transaction and wherein said taggingmeans is operable to append the generated session ID and the receivedsession ID to the message data.
 37. A smart-card according to claim 34,further comprising a money store for storing electronic money andwherein said tagging means is operable to tag said electronic money withsaid generated session ID and to output the tagged electronic money backto said external terminal via said interface means in said card reader.38. A smart-card according to claim 37, comprising means for storingremote account data and wherein said smart-card is operable to receivean instruction identifying whether or not payment for a currenttransaction is to be made from electronic money stored on the card orfrom the remote account and wherein said tagging means is operable totag said electronic money with said session ID if said instructionidentifies that the payment should be made from the card and is operableto tag the stored account data if said instruction indicates that thepayment is to be made from the remote account.
 39. A smart-cardaccording to claim 34, further comprising means for storing uservalidation data; means for receiving instructions to output uservalidation data; and wherein said tagging means is operable to tag theuser validation data with the session ID prior to outputting the taggedvalidation data to said external terminal via said interface means andsaid card reader.
 40. A smart-card according to claim 34, furthercomprising a transaction log store for storing details of datatransmitted during each new transaction.
 41. A smart-card comprising:means for interfacing with a card reader; a card controller operable forreceiving instructions from an external terminal via said interfacemeans and said card reader; means for storing electronic money; meansfor storing account data relating to a remote account; wherein said cardcontroller is operable to either output electronic money from said moneystore or to output account details from said account storing means independence upon instructions received from an external terminal via saidinterfacing means and said card reader.
 42. A smart-card according toclaim 41, wherein said card controller is operable to tag the electronicmoney or the account data with a unique identifier relating to a currenttransaction.
 43. An electronic transaction system comprising a vendor 15terminal, a purchaser terminal and a third party registry for providingvalidation of a purchaser associated with the purchaser terminal and/orvalidation of a vendor associated with the vendor terminal.
 44. A signalcarrying processor implementable instructions for causing a smart-cardto become programmed as a smart-card according to claim
 31. 45. Astorage medium storing processor implementable instructions for causinga smart-card to become programmed as a smart-card according to claim 31.46. A computer terminal programmed to function as a vendor terminalaccording to claim
 1. 47. A computer terminal programmed to function asa purchaser terminal according to claim
 24. 48. An electronictransaction payment characterized by the step of using an electronictransaction payment system according to claim 1.